Object orientation has been the most dominant methodology for developing software systems in the last two decades. Object oriented modeling (OOAD—Object Oriented Analysis and Design) started to show up in the late 1980's and has been used to “lift” concepts from the programming language level to a more abstract level using visual formalisms. The basic structural model for objects features a graphical notation for such OO notions as classes and instances, relationships and roles, and aggregation and inheritance. As to system behavior, there are two aspects that have to be modeled, the intra-object behavior which describes the way each one of the instances behaves, and the inter-object behavior which describes the interaction between objects in different possible scenarios of the system. As for the first aspect, most object-oriented modeling approaches adopted the statecharts language [1]. Each class is associated with a statechart that describes the behavior of the class instances. As for the second aspect, the most widely used language is message sequence charts (MSCs), adopted long ago by the International Telecommunication Union. MSCs is a visual language used to describe possible scenarios of a system behavior. In this language, objects are drawn as vertical lines and the communication between these objects is denoted by messages (horizontal lines going from the sending object to the receiving one). Messages in the language of MSCs may describe a wide variety of ‘real’ communications, such as actual messages sent on communication lines between computers, exchanging information using shared memory on a single machine, or even calling functions of one object by another one. Use cases were introduced in order to model the system by identifying the different observable behaviors and interactions of the system with the user.
In 1997 the Object Management Group (OMG) adopted the standard of UML (Unified Modeling Language) This standard encapsulates most of the ideas and notions mentioned above and brings them together as a single worldwide accepted standard. According to most UML-based methodologies for system development, the user first specifies the system's use cases. Then, the implementation of each use case is described using sequence diagrams (the UML name for MSCs). In a later modeling step, the behavior of each object is described by an associated statechart. Finally, each object is implemented as code in a specific programming language. Thus, for example, a use case may specify generally that “a client draws cash in an Automatic Teller Machine (ATM)”. This generalized observable behavior is described in a sequence of diagrams referring specifically to the various sequence of operations that constitute the use case of drawing cash. Thus, for example, a sequence diagram describes the step of feeding-in the client PIN and specifies a different treatment for (i) correct PIN or (ii) in-correct PIN (the latter allows, e.g. two additional retries). A specific sequence diagram is further provided for drawing cash within the client's authorized credit, or alternatively if the clients attempts to draw an amount which exceeds his/her credit (giving him/her opportunity to draw smaller amount), etc.
The process described above of specifying and developing systems can be partially automated (see a general discussion of this in [2]) and there are actually different implementations of some of the process steps. The most advanced automated part of the process is that of code generation from object diagrams and their statecharts, as implemented by two tools: RoseRT (by ObjectTime Inc.) and Rhapsody (by I-Logix Inc.). In 1999, Damm and Harel provided a rather extensive expansion of the system behavior specification language of MSCs to live sequence charts (LSCs) [3].
LSCs distinguish between scenarios that may happen in the system (existential) from those that must happen in it (universal). LSCs can further specify what messages may be accepted (cold) and what messages must (hot). Conditions are also handled with higher importance than in MSCs. Conditions may be cold, meaning that the condition may be true, or hot, meaning it must be true (otherwise the system aborts). Since its expressive power is far greater than that of MSCs, the language of LSCs makes it possible to attempt and transits between the first two modeling steps: LSCs and statecharts. Thus, in a recent paper [4], an algorithm for synthesizing statecharts automatically from LSCs specification is given, providing a first-cut treatment of automatically converting LSCs to statecharts. However, the transition from use cases to LSCs (or, for that matter, MSCs or any other language that describes inter-object behavior), is still done manually and is considered an art or a craft, besides requiring a deep knowledge of both the syntax and semantics of LSCs (or other specification languages). Before turning to FIG. 1, there follows a brief overview of system modeling. An indispensable part of any serious modeling approach is a rigorous semantical basis for the model constructed—notably, for the behavioral parts of the model and their connection with the structure. It is this semantics that leads to the possibility of executing models and running actual code generated from them (The code need not necessarily result in software; it could be in a hardware description language, leading to real hardware implementation). Obviously, if it is possible to generate full code, this code would eventually serve as the basis for the final implementation. Some current tools, like Statemate and Rhapsody from I-Logix, Inc., or Rose RealTime from Rational Corp. are in fact capable of producing quality code, good enough for the implementation of many kinds of reactive systems. And there is no doubt that the techniques for this kind of ‘super-compilation’ from high-level visual formalisms will improve in time. When developing a complex system, it is very important to be able to test and debug the model prior to investing extensively in implementation. Hence the desire for executable models. The basis for testing and debugging by executing the model are the requirements, which, by their very nature, constitute the constraints, desires and hopes concerning the system under development. It would be highly desired that both during development and afterwards that the system does, or will do, what it is intended to do.
The overall system modeling and design life cycle as practiced today is illustrated in FIG. 1, taken from [2]. Solid lines indicate that the used methodologies are automated or close to be, whereas dashed lines indicate methodologies that are not supported by any tools.
There is a need in the art to provide for a tool that offers playing-in and/or playing-out scenarios.